1. Statement of the Technical Field
The present invention relates to code analysis, and more particularly to performing selective data processing based upon a static analysis of code.
2. Description of the Related Art
Introduction
The modern programming language has evolved from little more than a listing of machine instructions which can be executed natively by a central processing unit, to a source code listing which can be compiled into native machine code. Intermediately, interpretable code, such as the BASIC computer language have provided the ability for an interpreter to parse and execute source code inline at run-time. Recently, programming languages have begun to conform to a new paradigm in which source code can be compiled into platform-independent byte code which subsequently can be executed by a run-time virtual machine.
The Java™ and C#™ programming languages and environments represent two such byte-code oriented programming languages. In the Java programming language, as in the case of the C# programming language, programs can be compiled into class objects consisting mainly of byte code. In the Java programming environment, a Java Virtual Machine™ (JVM) can interpret the byte code at run-time and can produce, as a result, machine code which can be executed by a host computing platform. Significantly, byte code can be serialized so as to enable the remote invocation and execution of compiled objects. Thus, byte code type programming languages represent the cutting edge of network enabled, distributed computer processing.
Byte-Code Analysis
Inasmuch as byte code can be interpreted by a virtual machine or some other such byte code processor, byte code can be analyzed not only post-compilation, but also pre-execution. That is to say, while traditional computer scientists have analyzed the likely operation of a computer program prior to compile time based upon the content of human readable source code, byte code analysis techniques have incorporated the static analysis of byte-code produced from human readable source code in order to achieve several objectives. Principal among those objectives, byte code analysis techniques can provide a method of predicting the behavior of a compiled object even when access to source code does not exist.
As a specific example, byte code analysis techniques have been used to optimize the execution of a compiled object. Similarly, byte code analysis techniques have been used to modify the behavior of a compiled object. Finally, byte code analysis techniques have been applied to compiled objects where the original source code associated with the compiled object no longer can be accessed. In all cases, to assist in the static analysis of byte code, several tools have been developed which can produce a visualization of the execution of a compiled object based upon the byte code of the compiled object.
Notably, the principals of byte code analysis can be applied to other types of intermediate code. For instance, object analysis and design tools have been configured to analyze the functionality and operational characteristics of both source code and object code. In particular, object code can be statically analyzed in a number of intermediate states, not only including byte code, but also including code of other intermediate states, such as the GNU gcc intermediate representation. In all cases, the code can be statically parsed to analyze the possible execution paths of the underlying logic of the code.
Entity Beans
While the Java programming language initially had been developed to support the notion of “write once, run anywhere” computing, the serialized nature in combination with the platform independence of Java objects can support enterprise computing efforts. To that end, Enterprise Java Bean™ (EJB) technologies have expanded upon the base Java programming language to provide an architecture for a transactional, distributed object system based on components. More particularly, the EJB 1.1 specification defines an architecture for the development and deployment of transactional, distributed object applications-based, server-side software components. These server-side components, referred to as enterprise beans, are distributed objects that are hosted in EJB containers and provide remote services for clients distributed throughout the network.
To create an EJB server-side component, an enterprise bean developer provides two interfaces that define a bean's business methods, in addition to the actual bean implementation class. The client then can use the bean's public interfaces to create, manipulate, and remove beans from the EJB server. The implementation class, referred to typically as the “bean class”, can be instantiated at runtime and can become a distributed object.
Enterprise beans “live” in an EJB container and can be accessed by client applications over the network through their remote and local interfaces. The remote and local interfaces expose the capabilities of the bean and provide each of the methods required to create, update, interact with, and delete the bean. There are two basic types of enterprise beans: entity beans, which represent data in a database, and session beans, which represent processes or act as agents performing tasks. The entity bean provides an object-oriented interface to data that would normally be accessed by a database connectivity application programming interface (API). Additionally, entity beans provide a component model that allows bean developers to focus their attention on the business logic of the bean, while the container manages persistence, transactions, and access control.
Passing Objects to an EJB
The EJB specification provides for the concept of a remote interface on an EJB in order both to abstract access to an EJB implementation, and also to make access to the EJB implementation highly portable. In that regard, to protect the caller of an EJB from the modification of the EJB by the caller, the EJB specification requires that objects passed to an EJB are to be passed by value rather than reference. This requirement is intended to preserve local/remote transparency in the EJB model. Yet, making a copy of an object is an expensive operation and, depending upon the application and use by the bean of non-primitive Java type, object copying can have a significant overall impact on performance.
Container Managed Persistence Beans
There are two types of entity beans: Container-Managed Persistence (CMP), and Bean-Managed Persistence (BMP). With a CMP bean, the container manages the persistence of the entity bean. Vendor tools are used to map the entity fields to the database and database access code need not be included in the bean class. In the case of a BMP bean, by comparison, the entity bean contains database access code and is responsible for reading and writing its own state to the database. Furthermore in the case of a BMP bean, the container can handle any locking or transactions, so that the database can maintain its integrity.
CMP beans often are viewed as the simplest bean for the bean developer to create, yet the most difficult for the EJB server to support. This is so because all of the logic for synchronizing the bean's state with the database is handled automatically by the container. Consequently, the bean developer need not write data access logic for the bean as the EJB server purportedly handles all of the persistence needs of the bean automatically. Still, while most EJB implementations support automatic persistence to a relational database, the level of support can vary. Some EJB implementations can provide very sophisticated Object-to-Relational mapping, while others are very limited.
In the typical implementation, a CMP entity bean can defer all interaction with an underlying database to an EJB container. The CMP entity bean, in turn, can expose a set of methods that permit the data in the database to be referenced or updated by other application processes. When the container reads the data from the database, the container can place the data into fields of the CMP entity bean. Subsequently, application processes can reference and update the data in the fields. At the conclusion of a transaction, the container can access the data in the CMP entity bean and can update the underlying row in the table of the database.
Notably, the CMP entity bean style of mapping a relational database to an object can provide a significant benefit as access to the data in the database can be greatly simplified and can be used by a number of application processes. Notwithstanding, the conventionally known CMP entity bean style also can prove deficient in terms of efficiency and performance. Specifically, in a simple model, all data in the CMP entity bean, whether updated or otherwise, will result in the container writing the data back to the database. Where no modifications to the data have been performed in the CMP entity bean, an unnecessary write will occur in the database at the conclusion of the transaction.
Notably, writing to a relational database can be an expensive operation. At the minimum, storing data that has only been referenced, but not modified, can result in the execution of a time-consuming database write operation yielding no end-user benefit. Furthermore, in addition to the execution of a structured query language (SQL) statement to update the table in the database, often it is necessary to upgrade a lock from a read-only state to an exclusive state. At best, the upgrade can increase response time. In the worst case scenario, however, the upgrade can result in a deadlock resulting from lock promotion.